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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 3 of a multi-part deliverable covering the end-to-end Quality of Service in TIPHON 
Systems, as identified below: 

TR 102 024-1: "General aspects of Quality of Service (QoS)"; 

TS 102 024-2: "Definition of Speech Quality of Service (QoS) Classes"; 

TS 102 024-3: "Signalling and Control of end-to-end Quality of Service (QoS) in a multi-media environment"; 

TS 102 024-4: "Quality of Service Management" ; 

TS 102 024-5: "Quality of Service (QoS) measurement methodologies"; 

TR 102 024-6: "Actual measurements of network and terminal characteristics and Performance parameters in 
TIPHON networks and their influence on voice quality"; 

TR 102 024-7: "Design Guide for elements of a TIPHON connection from an end-to-end speech transmission 
performance point of view"; 

TS 102 024-9: "Call performance Classification (Voice)"; 

TS 102 024-10: "QoS Requirements for TIPHON Terminals". 
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Scope 



The present document, "TIPHON signalling and control of end-to-end Quality of Service (QoS)", specifies procedures 
for the control of end-to-end QoS within and between domains. TS 101 882 (see bibliography) specifies the TIPHON 
meta-protocols and object definitions required by these control procedures. 

Additional annexes to the present document define profiles for mapping a number of existing candidates protocols to 
the specified TIPHON meta-protocols. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

name: unique identifier by which a user, access or terminal is known within a TIPHON system 

TIPHON system: system that complies with the mandatory requirements identified in the TIPHON specifications 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ASN. 1 Abstract Syntax Notation 1 

COPS Common Open Policy Service 

OSP Open Settlement Protocol 

QFE QoS Functional Entity 

QoS Quality of Service 

RSVP resource ReSerVation Protocol 

RTP/AVP Real-Time Protocol Audio- Video Profile 

SCN Switched Circuit Network 

SDL Specification and Description Language 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

4 End-to-end QoS Signalling functional requirements 

4.1 Description 
4.1.1 General description 

End-to-end QoS Signalling is used within a TIPHON network to ensure that a caller is provided with an end-to-end 
connection having at least the QoS class subscribed to or a lower QoS class if this is acceptable to the user. A QoS level 
may either be requested explicitly by the user on a call-by-call basis or may be predefined as part of the user's 
subscription. Additionally, the caller may be able to take specific actions if the QoS moves outside the accepted level 
during an established call. 

The user may use any of the following methods to request a specific end-to-end QoS at call establishment: 

1) By subscription: 

The agreement between the user and the user's service provider identifies the QoS level to be requested for any 
call. The QoS level may be fixed or variable based upon such parameters as time-of-day and call destination. 
This method requires no signalling between the user and the service provider at call setup time. 
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2) By the use of a standardized TIPHON QoS Class: 



The user indicates at each call establishment which of the TIPHON QoS Classes (standardized in 
TS 102 024-2 [4]) is to be requested for the call. The TIPHON QoS Classes are identified as: 



Class 1 


Best effort; 


Class 2A 


Acceptable; 


Class 2M 


Medium; 


Class 2H 


High; 


Class 3 


Best (broadband); 



3) By the use of a non-standardized QoS Class: 

The user indicates at each call establishment which non-standardized QoS class is to be requested for the call. 
The QoS class may represent any combination of QoS parameters previously agreed between the user and the 
service provider. 

4.2 Procedures 

4.2.1 Provision and withdrawal 

End-to-end QoS Signalling shall be provided on a per-name, per application basis to all subscribers to the simple call 
within a TIPHON system. 

When establishing a call, a user shall be able to select at least one of the options identified in table 1 . 

Table 1 : QoS option 



Option 


Value 


QoS class 


- Predefined by user and service provider (TIPHON or non-TIPHON class) 

- TIPHON Best - QoS Class 3 (see note 1) 

- TIPHON High - QoS Class 2H (see note 1) 

- TIPHON Medium - QoS Class 2M (see note 1) 

- TIPHON Acceptable - QoS Class 2A (see note 1 ) 

- TIPHON Best effort - QoS Class 1 (see note 1 ) 

- Non-TIPHON QoS Class (see note 2) 


NOTE 1 : This value shall be as defined in TS 1 02 024-2 [4]. 

NOTE 2: This may be any value agreed between the user and the service provider to indicate a specific QoS 



4.2.2 Normal procedures 

4.2.2.1 Activation, deactivation and interrogation 

QoS Signalling shall be permanently activated. 

4.2.2.2 Invocation and operation 

When establishing a simple call, the calling user (or an agent within the user's network) may request a TIPHON 
standardized QoS class or a non-standardized QoS class, to be applied to the call in order to achieve a required 
end-to-end QoS. 

If the end-to-end QoS requested by the calling user is available, communication using that QoS shall be established 
following the simple call procedures specified in TS 101 878 [3], 
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4.2.3 Exceptional procedures 
4.2.3.1 Invocation and operation 

If it is not possible to offer the requested end-to-end QoS at call establishment, the calling user shall be informed and 
may take one of the following actions: 

terminate the call attempt; 

request a lower QoS; 

proceed with the call at the QoS available between the caller and the called user. 

If, during an established call, the end-to-end QoS perceived by the calling user falls below an acceptable level the 
following practical options are available: 

terminate the call; 

continue with the call at the inferior QoS level. 

4.3 Interactions with other TIPHON service capabilities 

This clause specifies interactions with other TIPHON services for which standards were available at the time of 
publication of the present document. 

4.3.1 Registration service capabilities 

4.3.1 .1 Terminal transport service registration 

No interaction. 

4.3.1 .2 User service registration 

No interaction. 

NOTE: The QOS to be used for subsequent calls by the registered user may form part of the information supplied 
at registration. 

4.3.2 Call connectivity service capabilities 

4.3.2.1 Simple call establishment 

No interactions. 

4.3.2.2 Calling user identity generation 

No interactions. 

4.3.2.3 Calling user identity conveyance 

No interactions. 

4.3.2.4 Calling user identity delivery 

No interactions. 
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4.3.2.5 Call rejection 

No interactions. 

4.3.2.6 Number portability 

4.3.2.6.1 Number portability - All call query 

No interactions. 

4.3.2.6.2 Number portability - Query on release 

No interactions. 

4.3.2.6.3 Number portability - Pivot routing (Drop back) 

QoS Signalling shall be terminated prior to the invocation of the pivot routing service capability and then re-invoked 
after the drop back has occurred. 

4.3.2.7 Emergency calls 

4.3.2.7.1 Emergency Calling Service (ECS) 

No interactions. 

4.3.2.7.2 Authorized emergency priority calls 

Insufficient QoS availability shall not cause the rejection of an authorized emergency priority call. 

4.3.2.8 Bearer connectivity 

4.3.2.8.1 Bearer creation 

No interactions. 

4.3.2.8.2 Bearer negotiation 

The user's requested QoS should be one of the parameters used in bearer negotiation. 

4.3.2.8.3 Bearer re-negotiation 

The user's requested QoS should be one of the parameters used in bearer re-negotiation. 

4.3.2.8.4 Media path optimization 

The selection of an optimum path which is different from that selected at call establishment shall not cause an adverse 
effect on the perceived QoS of the call. 

4.3.2.9 Event recording 

No interactions. 

4.3.2.10 Third party authorization 

When a call is established using third party authorization, the requested QoS shall be that of the original calling user, 
not that of the third party. 
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4.3.2.1 1 Overlap sending 

No interactions. 

4.4 Interworking considerations 

When interworking with a Switched Circuit Network (SCN) where the only variable affecting QoS is the choice of 
bearer service, fixed QoS parameters shall be assumed based on the bearer service selected. 

4.5 Overall behaviour 

Figure 1 contains the dynamic description of end-to-end QoS Signalling using a Unified Modeling Language (UML) 
activity diagram. The activity diagram represents the behaviour of a TIPHON system in providing end-to-end QoS 
Signalling. 

NOTE: The syntax and semantics of UML diagrams are defined by the Object Management Group (OMG). 
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Figure 1 : Overall behaviour of end-to-end QoS Signalling at call establishment 
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5 Functional entity model and information flows 

5.1 Functional entity model 
5.1 .1 Description of model 

The functional model shall comprise the following QoS Functional Entities (QFE): 

Calling User The application at the calling user's terminal which instigates the service request. 
QFE1 The service agent that processes the calling user's request for end-to-end QoS signalling. 

QFE2 The originating QoS coordination function. This QFE is responsible for negotiating and 

establishing a particular QoS on behalf of the calling user. 
QFE3 The terminating QoS coordination function. This QFE is responsible for establishing a particular 

QoS on behalf of the called user. 
QFE4 The service agent that processes an incoming call to the called user. 

QFE5 The QoS policy control function associated with the calling user's service provider. 

QFE6 The transport coordination function serving the calling user. 

QFE7 The transport coordination function serving the called user. 

QFE8 An intervening QoS coordination function. This QFE is responsible for establishing a particular 

QoS within an intervening domain. 
QFE9 An intervening transport coordination function. 

Called User The application in the called user's terminal at which the service request is terminated. 

The following functional relationships shall exist between these QFEs: 

ra between the Calling User and the Calling User's service agent (QFE1). 

rb between the Calling User's service agent (QFE1) and the Calling User's QoS coordination function 

(QFE2). 
re between QoS coordination functions in the originating side (QFE2) and an intervening QoS 

coordination function (QFE8). 
rd between an intervening QoS coordination function (QFE8) and the Called User's QoS coordination 

function (QFE3). 
re between the Called User's QoS coordination function (QFE3) and the Called User's service agent 

(QFE4). 
rf between the Called User's service agent (QFE4) and the Called User, 

rg between the Calling User's service agent (QFE1) and the QoS Policy Control function associated 

with the Calling User (QFE5). 
rh between the originating QoS coordination function (QFE2) and the originating transport 

coordination function (QFE6). 
ri between an intervening QoS coordination function (QFE8) and the transport coordination function 

associated with it (QFE9). 
rj between the terminating QoS coordination function (QFE3) and the terminating transport 

coordination function (QFE7). 

Figure 2 shows the Functional Entities (QFE) and the relationships between them. 
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Figure 2: End-to-end QoS signalling functional entity model 



5.1 .2 Description of functional entities 



5.1.2.1 



Calling User 



The Calling User functional entity acts on behalf of the human user to request the establishment of an end-to-end call 
with a specific QoS. 

5.1 .2.2 Calling User's service agent, QFE1 

On receipt of a QoS establishment request from the Calling User, QFE1 determines whether current policy permits the 
requested QoS to be used with the call and either initiates a simple call establishment request towards the destination 
address or rejects the call request back to the calling user. 

5.1 .2.3 The originating QoS coordination function, QFE2 

This QFE requests the provision of a bearer capable of supporting the desired end-to-end QoS and passes on the simple 
call request towards QFE3. 

5.1 .2.4 The terminating QoS coordination function, QFE3 

QFE3 requests the provision of a bearer capable of supporting the desired end-to-end QoS and passes on the simple call 
request to QFE4. 

5.1 .2.5 The called user's incoming call service agent, QFE4 

This QFE informs the called user that the requested QoS is required with the associated incoming simple call. 

5.1 .2.6 The QoS policy control function associated with the calling user's service 
provider, QFE5 

This QFE consults its current service database to determine whether the calling user is permitted to make a call with the 
requested end-to-end QoS to the indicated called user. 

5.1 .2.7 The transport coordination function serving the calling user, QFE6 

This QFE attempts to establish a bearer connection between the indicated incoming user access point and an appropriate 
outgoing network access point capable of providing the requested end-to-end QoS. 
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5.1 .2.8 The transport coordination function serving the called user, QFE7 

This QFE attempts to establish a bearer connection between the indicated incoming network access point and an 
appropriate outgoing user access point capable of providing the requested end-to-end QoS. 

5.1 .2.9 An intervening QoS coordination function, QFE8 

If present, this QFE requests the provision of a bearer capable of supporting the desired end-to-end QoS and passes on 
the simple call request towards QFE3. 

5.1 .2.1 An intervening transport coordination function, QFE9 

If present, this QFE attempts to establish a bearer connection between the indicated incoming network access point and 
an appropriate outgoing network access point capable of providing the requested end-to-end QoS. 

5.1.2.11 Called User 

The Called User functional entity acts on behalf of the human user to accept the establishment of an end-to-end call 
with a specific QoS. 

5.2 Information flows 

5.2.1 Definition of information flows 

NOTE: In the tables within this clause, the following convention is used in the "Value" columns. Un-bulleted lists 
of values indicate that all items in the list are included in the associated information element; bulleted lists 
of values indicate that only one item in the list is included in the information element. 

5.2.1.1 Relationship ra 

5.2.1.1.1 OrigQoSEstab 

OrigQoSEstab is a confirmed information flow that shall be sent across relationship ra from the calling user to QFE1 
to indicate a request for a new call establishment with a specific end-to-end QoS. Table 2 lists the elements within the 
OrigQoSEstab information flow. 
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Table 2: Content of OrigQoSEstab 



OrigQoSEstab 


Information element 


Value 


Request 


Response 


QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


M 




Called user ID 


TIPHON user name 


M 




Codec 


- List of possible codecs 
Codec type 
Frames per packet 


M 


O 
(see notes 1 and 2) 


Result 


- End-to-End QoS Established 

with requested QoS 

- Rejection cause 

Requested QoS not available 
Called user unknown 
No compatible codec available 
Policy Rejection 




M 


NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the Result element is set to "end-to-end QoS Established". 



5.2.1.2 



Relationships rb, re, rd and re 



5.2.1.2.1 



QoSEstab 



QoSEstab is a confirmed information flow that shall be sent across relationships rb, re, rd and re to indicate a request 
for the provision of a guaranteed end-to-end QoS for the associated TIPHON simple call. Table 3 lists the elements 
within the QoSEstab information flow. 

Table 3: Contents of QoSEstab 



QoSEstab 


Information element 


Value 


Request 


Response 


Calling user ID 


TIPHON user name 


M 




Called user ID 


TIPHON user name 


M 




Transport QoS parameters 


Maximum delay, 

Maximum packet delay variation, 

Maximum mean packet loss 


M 




Transport parameters qualifier 


- Transport QoS parameters indicate total 

remaining budget 

- Transport QoS parameters indicate budget 

available per domain 


M 




Traffic descriptor 


Media peak rate, 
Maximum media frame size, 


M 




Codec 


List of possible codecs 
Codec type 
Frames per packet 


M 


O 
(see notes 1 and 2) 


Destination service domain 


Network specific address 


O 




Result 


- Requested QoS available 

- Rejection cause 

Requested QoS not available 

Called user unknown 

No compatible codec available 




M 


NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is "Requested QoS available". 
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5.2.1.3 



Relationship rf 



5.2.1.3.1 



DestQoSEstab 



DestQoSEstabisa confirmed information flow that shall be sent across relationship rf from QFE4 to the called user 
to indicate a request for a new call establishment with a specific end-to-end QoS. Table 4 lists the elements within the 
DestQoSEstab information flow. 

Table 4: Contents of DestQoSEstab 



DestQoSEstab 


Information element 


Value 


Request 


Response 


Calling user ID 


TIPHON user name 


M 




Transport QoS parameters 


Maximum delay, 

Maximum packet delay variation, 

Maximum mean packet loss 


M 




Codec 


List of possible codecs 
Codec type 
Frames per packet 


M 


O 
(see notes 1 and 2) 


Result 


Indicated codec selected 
Rejection cause: 
Codecs not supported 




M 


NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is "Indicated codec selected". 



5.2.1.4 



Relationship rg 



5.2.1.4.1 



QoSPolicy 



QoSPolicy is a confirmed information flow that shall be sent across relationship rg from QFE1 to QFE5 to request 
permission for a new call establishment with a specific end-to-end QoS. Table 5 lists the elements within the 
QoSPolicy information flow. 

Table 5: Contents of QoSPolicy 



QoSPolicy 


Information element 


Value 


Request 


Response 


Calling user ID 


TIPHON user name 


M 




Called user ID 


TIPHON user name 


M 




Transport QoS parameters 


Maximum delay, 

Maximum packet delay variation, 

Maximum mean packet loss 


O 

(see note) 




QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


O 

(see note) 




Result 


- Call permitted 

- Rejection cause 

Service not subscribed to 
Service currently not available 




M 


NOTE: One of these information elements shall be provided. 
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5.2.1.5 



Relationships rh, ri and rj 



5.2.1.5.1 



TRMReserve 



TRMRe serve is a confirmed information flow that shall be sent across relationships rh, ri and rj to request the 
reservation of a media transport path with a specific end-to-end QoS towards the called user's address. Table 6 lists the 
elements within the TRMReserve information flow. 

Table 6: Contents of TRMReserve 



TRMReserve 


Information element 


Value 


Request 


Response 


Traffic identifier 


Alphanumeric "handle" 


M 




Transport QoS parameters 


Maximum delay, 

Maximum packet delay variation, 

Maximum mean packet loss 


M 


O 

(see note) 


Transport parameters qualifier 


Transport QoS parameters indicate total 
remaining budget 

Transport QoS parameters indicate budget 
available per domain 


M 




Traffic descriptor 


Media peak rate, 
Maximum media frame size 


M 




Source transport domain 


Network specific address 


M 




Destination transport domain 


Network specific address 


M 




Result 


Requested resources reserved 
Rejection cause 

Requested resources not available 
Destination unknown 




M 


NOTE: This information element shall be included if the value of the transport parameters qualifier in the request is 
"Transport QoS parameters indicate total remaining budget". 



5.2.1.5.2 



TRMConnect 



TRMConnect is a confirmed information flow that shall be sent across relationships rh, ri and rj to request the 
establishment of a previously reserved media transport path call with a specific end-to-end QoS towards the called 
user's address. Table 7 lists the elements within the TRMConnect information flow. 

Table 7: Contents of TRMConnect 



TRMConnect 


Information element 


Value 


Request 


Response 


Traffic identifier 


Alphanumeric "handle" 


M 




Result 


Reserved connection completed 

Rejection cause 

Unable to complete connection 




M 



5.2.1.5.3 



TRMRelease 



TRMRelease is an unconfirmed information flow that shall be sent across relationships rh, ri and rj to request that a 
previously reserved media transport path is released as it is no longer required. Table 8 lists the elements within the 
TRMRelease information flow. 

Table 8: Contents of TRMRelease 



TRMRelease 


Information element 


Value 


Request 


Traffic identifier 


Alphanumeric "handle" 


M 
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5.2.2 Relationship of information flows to TIPHON simple call 

Table 9 specifies the relationships of the end-to-end QoS information flows with those of the TIPHON Simple Call 
(see TS 101 882-3 in bibliography). 

Table 9: Relationship of the End to End QoS information flows with the TIPHON Simple Call 



Information flow 


Independent of 
simple call flow 


With simple 
call flow 


Simple call flows 


ra 


OrigQoSEstab 


request 


no 


yes 


TCC OrigCallSetup (req) 


response 


no 


yes 


TCC OrigCallSetup (resp) 


rb 


QoSEstab 


request 


no 


yes 


CallSetup (req) 


response 


no 


yes 


CallSetup (resp) 


re 


QoSEstab 


request 


no 


yes 


NWCallSetup (req) 


response 


no 


yes 


NWCallSetup (resp) 


rd 


QoSEstab 


request 


no 


yes 


NWCallSetup (req) 


response 


no 


yes 


NWCallSetup (resp) 


re 


QoSEstab 


request 


no 


yes 


DestCallSetup (req) 


response 


no 


yes 


DestCallSetup (req) 


rf 


DestQoSEstab 


request 


no 


yes 


TCC DestCallSetup (req) 


response 


no 


yes 


TCC DestCallSetup (resp) 


rg 


QoSPolicy 


request 


no 


yes 


QoSPolicy (req) 


response 


no 


yes 


QoSPolicy (resp) 


rh 


TRMReserve 


request 


no 


yes 


TRMReserve (req) 


response 


no 


yes 


TRMReserve (resp) 


TRMConnect 


request 


no 


yes 


TRMConnect (req) 


response 


no 


yes 


TRMConnect (resp) 


TRMRelease 


request 


no 


yes 


TRMRelease (req) 


ri 


TRMReserve 


request 


no 


yes 


TRMReserve (req) 


response 


no 


yes 


TRMReserve (resp) 


TRMConnect 


request 


no 


yes 


TRMConnect (req) 


response 


no 


yes 


TRMConnect (resp) 


TRMRelease 


request 


no 


yes 


TRMRelease (req) 


rj 


TRMReserve 


request 


no 


yes 


TRMReserve (req) 


response 


no 


yes 


TRMReserve (resp) 


TRMConnect 
TRMRelease 


request 


no 


yes 


TRMConnect (req) 


response 


no 


yes 


TRMConnect (resp) 


request 


no 


yes 


TRMRelease (req) 



5.2.3 Timers 



5.2.3.1 



Reservation Hold Timers 



Within each of QFE6, QFE7 and QFE9, a Reservation Hold Timer is used to ensure that resources reserved with a 
TRMReserve information flow are not held indefinitely if a subsequent TRMConnect information flow is not 
received. The period of a Reservation Hold Timer is implementation dependent but shall be in the range of 8 seconds to 
15 seconds. 



5.2.4 Information flow sequences 



A standard specifying TIPHON meta-protocols for end-to-end QoS Signalling shall provide signalling procedures in 
support of the information flow sequences specified below. In addition, signalling procedures should be provided to 
cover other sequences arising from error situations, interactions with simple call and interactions with other service 
capabilities. 

In the figures, end-to-end QoS Signalling information flows are represented by solid arrows. Within a column 
representing a QoS Signalling functional entity, the numbers refer to functional entity actions listed in clause 5.3. 

The following abbreviations are used: 
req request; 

resp response. 
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5.2.4.1 Normal operation 

Figure 3 shows the information flows for the successful establishment of end-to-end QoS. 
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Calling 
User 



QFE1 



OrigQaSEstab.req. 



■ OrigQoSEstab.resf 



102 



,103 



QFE5 



501 



QoSEstab. req 



rd 



QFE2 



QoSEstab. resp 



QFE6 



TR M^eser^. r 



TR r^R eserue. resp 



TRM^onnectreq . 



TRI^Connect resj. i 



601 



Reserve Timer 



602 



QFE8 



■¥< 



QoSEstab. icsp 



803 



QFE9 



TR ^-Reserve, req 



TRI^Reserve.resp 901 — 5? 



QoSEstab. req 



TR MZonnect req 



TR M^onnect resp 



902 



QFE3 



Reserve Timer 



QoSEstab. resp 



X 



303 



QFE7 



TR I^Reserx^. req 



TRI^Reser\e. rest: 



TRM^onnect req < 



/ TRMZonneQtrest.702 — ^^ 



QFE4 



Reserve Timer 



QoSEstab. resp ' 



Called 
User 



DestQoSEstab. 



req. 



DestQoSEstab. res ) 



Figure 3: Information flows for successful QoS establishment 
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The information flows in figure 3 for successful QoS establishment can also be expressed in the form of a UML collaboration diagram as shown in figure 4. 



QFE5 



Calling 
User 



2: QoSPolicy.req 
1 : OrigQoSEstab.req 



-> 



<r 



QFE1 



3: QoSPolicy.resp 



4: QoSEstab.req 
> 



26: OrigQoSEstab.resp 



f- 



QFE2 



25: QoSEstab.resp 



6: TRMReserve.resp 



24: TRMConnect.resp 



7: QoSEstab.req 
> 



f- 



QFE8 



22: QoSEstab.resp 

9: TRMReserve.resp 
5: TRMReserve.req 

21 : TRMConnect.resp 
23: TRMConnect.req 



QFE6 



10: QoSEstab.req 
> 



<- 



QFE3 



19: QoSEstab.resp 

8: TRMReserve.req 

1 2: TRMReserve.resp 

20: TRMConnect.req 

1 8: TRMConnect. resp 



QFE9 



13: QoSEstab.req 
> 



{- 



16: QoSEstab.resp 



1 1 : TRMReserve.req 



17: TRMConnect.req 



QFE7 



Figure 4: Successful QoS establishment shown in a collaboration diagram 
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5.2.4.2 Exceptional behaviour 

Figure 5 shows the information flows for the rejection of QoS establishment due to the requested end-to-end QoS being unavailable. 

rb re rd 
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Calling 
User 



QFE1 



OigQoSEstab. req , 



OrigQoSEstab. resf i 



(QoSNotA\£iilable 



101 



QFE5 



QoSPo Iky. resp 



QoSEstab.req 



] [ 



QFE2 



QoSEstab. resfi 



(QoSNotA-uailable) 



QFE6 



TR I^Reser\,e. req 



TR I^Reser\^. resf 



TR IVRelease. req 



601 



QFE8 



Reserve Timer 



QoSEsta b. resp 



(QoSNotAxsiable) 



QFE9 



TRM^eser^. req 



TRI^Reserx^. resp 



TRIVRelease. req 



901 -% 



QFE3 



Reserve Timer 



QoSEsrab. resp 



(QoSNotAwailable) 



X 



301 



QFE7 
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TRM^eserv^. resf 



(OoSNotAwaibble) 



Figure 5: Information flows for unsuccessful establishment due to QoS not available 
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Figure 6 shows the information flows for the rejection of a QoS establishment due to policy conflict. 

rb re 



Calling 
User 



QFE1 



OrigQoSEstab. req , 



OrigQoSEstab. resr. 



( Po lioyRejection) 
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QFE5 



OoSPolky. resp 



502 



(RequestRejected 



rd 



QFE2 



rh 



QFE6 



QFE8 



CFE9 
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QFE7 



Figure 6: Information flows for the rejection of QoS establishment due to a policy decision 
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Figure 7 shows the information flows for the rejection of a QoS establishment because a compatible codec is not available at the called user. 

rb re rd re 
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Calling 
User 



QFE1 



OrigQoSEstab. req . 



OtigQoSEstab. resf H Q4 
((NuCu i I fjdUU I tdCudt r 



102 



rg 



QFE5 



QFE2 



QoSEstab.nBsr: 



(NoConpatibleCode ) 



rh 



QFE6 



TR[^Reser\^. req 



TR I^Reser\,e. resf 



TR [^Release, req 



601 -K 



603 



QFE8 



Reserve Timer 



QoSEstab. resp: 



(NoConpatibleCode ) 



802 



804 



QFE9 



TR[^Reser\^. req 



TRI^Reserve.resp 90"! 7\ 



TR [^Release, req 



QFE3 



Reserve Timer 



QoSEstab. resp 



(NoCorrpatibleCodec ) 

■4< 



QFE7 



TR|\^Reser\,e.req 



TR|\^Reser\je. resf 



TR [^Release, req 



701^ 



QFE4 



Reserve Timer 



QoSEslab. resp 



(NoCorrpatJbleCodec j 



Called 
User 



DestQoSEstab. 



nsg. 



DestQoSEstab. re; 3 



(CodecNotSupporte d) 



Figure 7: Information flows for the rejection of QoS establishment because a compatible codec is not available 
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Figure 8 shows the information flows for the rejection of a QoS establishment because a the resources reserved with a TRMReserve are no longer available when the 
TRMConnect is sent even though the Hold Reservation Timer has not expired. 

rb re rd re 



Calling 
User 



QFE1 



OrigCOSEstab.req, 



OrigQoSEstab.res > 



(QoSNotA-uaiable 



101 



,104 



rg 



QFE5 



QoSPolky. resp 



QFE2 



QoSEsrab. resp 



(QoSNotA-ueilable) 



204 



QFE6 



TR [^Reserve, req 



TRMReserve. resp 



TR [^Release, req 



603 



] [ 



QFE8 



Reser\« Timer 



QoSEstabresp 



(QoSNotAaiable) 



801 



802 
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QFE9 



TRMReserve. req 



TR MReserve. resr; 
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QFE3 
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X 



QFE7 
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Reserve Timer 



QFE4 



QoSEstab. resp ' 



Called 
User 



DestQoSEstBb.n 



DestQoSEstab. res > 



Figure 8: Information flows for the rejection of QoS establishment due to unavailability of previously reserved media transport resources 
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Figure 9 shows the information flows for the rejection of a QoS establishment because a the resources reserved with a TRMReserve are no longer available when the 
TRMConnect is sent because the Hold Reservation Timer has expired. 
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Figure 9: Information flows for the rejection of QoS establishment due to a resource time-out 
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5.3 QoS Functional entity actions 

Throughout the descriptions of QFE actions, the following conventions are used to identify information flows: 

An information flow is referred to as a "request" at the QFE that sends it and as an "indication" at the QFE that 
receives it. 

The corresponding confirmation is referred to as a "response" at the QFE that sends it and as a "confirmation" 
at the QFE that receives it. 

The following QFE actions shall occur at the points indicated in the figures of clause 5.2.4. 

5.3.1 Actions of QFE1 

101: On request from the Calling User (OrigQoSEstab indication), determine transport parameters to be 

used, formulate a QoSPolicy request and send it to QFE5. 
102: Receive a positive QoSPolicy confirmation indicating that the call is permitted with the requested 

QoS, formulate a QoSEstab request and send it to QFE2. 
103: Receive a positive QoSEstab confirmation, formulate a positive OrigQoSEstab response and send 

it to the Calling User. 
104: Receive a negative QoSEstab confirmation, formulate a corresponding negative OrigQoSEstab 

response and send it to the Calling User. 
105: Receive a negative QoSPolicy confirmation, formulate a corresponding negative OrigQoSEstab 

response and send it to the Calling User. 
106: Receive a positive QoSPolicy confirmation indicating that the call is permitted but with an 

alternative QoS to that requested by the Calling User, formulate a QoSEstab request and send it to 

QFE2. 
107: Receive a positive QoSEstab confirmation, formulate a positive OrigQoSEstab response indicating 

that an alternative QoS to that requested has been used and send it to the Calling User. 

5.3.2 Actions of QFE2 



201: Receive a QoSEstab indication, formulate a TRMReserve request and send it to QFE6. 

202: Receive a positive TRMReserve confirmation, formulate a QoSEstab request and send it to QFE8. 

203: Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE6. 

On receipt of a positive TRMConnect confirmation, send a positive QoSEstab response to QFE1. 
204: Receive a negative QoSEstab confirmation, send a TRMRelease request to QFE6 and send a 

negative QoSEstab response to QFE1. 
205 (not shown): Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE6. 

On receipt of a negative TRMConnect confirmation, formulate a negative QoSEstab response, 

send it to QFE1 and stimulate the release of the TIPHON Simple Call towards the Called User. 



5.3.3 Actions of QFE3 



301: Receive a QoSEstab indication, formulate a TRMReserve request and send it to QFE7. 

302: Receive a positive TRMReserve confirmation, formulate a QoSEstab request and send it to QFE4. 

303: Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE7. 

On receipt of a positive TRMConnect confirmation, send a positive QoSEstab response to QFE8. 

Receive a negative TRMReserve confirmation, formulate a negative QoSEstab response and send 

it to QFE8. 

Receive a negative QoSEstab confirmation, send a TRMRelease request to QFE7 and send a 

negative QoSEstab response to QFE8. 
306 (not shown): Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE9. 

On receipt of a negative TRMConnect confirmation, formulate a negative QoSEstab response, 

send it to QFE2 and stimulate the release of the TIPHON Simple Call towards the Called User. 



304: 



305: 
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5.3.4 Actions of QFE4 



401: Receive a QoSEstab indication, formulate a DestQoSEstab request and send it to the Calling User. 

402: On request from the Calling User (positive DestQoSEstab confirmation), formulate a positive 

QoSEstab response and send it to QFE3. 
403: On request from the Calling User (negative DestQoSEstab confirmation), formulate a negative 

QoSEstab response and send it to QFE3. 

5.3.5 Actions of QFE5 

501: Receive a QoSPolicy indication. If the established policy permits the call to proceed with the 

requested QoS, formulate a positive QoSPolicy response and send it to QFE1. 

502: Receive a QoSPolicy indication. If the established policy does not permit the call to proceed with 

the requested or an alternative QoS, formulate a negative QoSPolicy response and send it to QFE1. 

503: Receive a QoSPolicy indication. If the established policy does not permit the call to proceed with 

the requested QoS but would allow it to proceed with an alternative QoS, formulate a positive 
QoSPolicy response indicating the alternative QoS parameters and send it to QFE1. 

5.3.6 Actions of QFE6 

601: Receive a TRMReserve indication. If it is possible to meet the requested QoS demands, formulate 

a positive TRMReserve response, send it to QFE2 and start the QFE6 Reservation Hold Timer. 

602: Receive a TRMConnect indication. If the reserved resources are still available, finalize the 

allocation of the resources and formulate a positive TRMConnect response and send it to QFE2. 

603: Receive a TRMConnect indication. If the reserved resources are no longer available, formulate a 

negative TRMConnect response and send it to QFE2. 

604 (not shown): Receive a TRMReserve indication. If it is not possible to meet the requested QoS demands, 

formulate a negative TRMReserve response and send it to QFE2. 

605 (not shown): When the Reservation Hold Timer expires, release the reserved resources and set an indication that 

they are no longer available. 

5.3.7 Actions of QFE7 

701: Receive a TRMReserve indication. If it is possible to meet the requested QoS demands, formulate 

a positive TRMReserve response, send it to QFE3 and start the QFE7 Reservation Hold Timer. 
702: Receive a TRMConnect indication. If the reserved resources are still available, finalize the 

allocation of the resources and formulate a positive TRMConnect response and send it to QFE3. 
703: Receive a TRMConnect indication. If the reserved resources are no longer available, formulate a 

negative TRMConnect response and send it to QFE3. 
704: Receive a TRMReserve indication. If it is not possible to meet the requested QoS demands, 

formulate a negative TRMReserve response and send it to QFE3. 
705 (not shown): When the Reservation Hold Timer expires, release the reserved resources and set an indication that 

they are no longer available. 

5.3.8 Actions of QFE8 

801: Receive a QoSEstab indication, formulate a TRMReserve request and send it to QFE9. 

802: Receive positive TRMReserve confirmation, formulate a QoSEstab request and send it to QFE3. 

803: Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE9. 

On receipt of a positive TRMConnect confirmation, send a positive QoSEstab response to QFE2. 
804: Receive a negative QoSEstab confirmation, send a TRMRelease request to QFE9 and send a 

negative QoSEstab response to QFE2. 
805: Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to QFE9. 

On receipt of a negative TRMConnect confirmation, formulate a negative QoSEstab response, 

send it to QFE2 and stimulate the release of the TIPHON Simple Call towards the Called User. 



ETSI 



30 ETSI TS 1 02 024-3 V4.1 .1 (2003-01 ) 



5.3.9 Actions of QFE9 



901: Receive a TRMReserve indication. If it is possible to meet the requested QoS demands, formulate 

a positive TRMReserve response, send it to QFE8 and start the QFE9 Reservation Hold Timer. 
902: Receive a TRMConnect indication. If the reserved resources are still available, finalize the 

allocation of the resources and formulate a positive TRMConnect response and send it to QFE8. 
903: Receive a TRMConnect indication. If the reserved resources are no longer available, formulate a 

negative TRMConnect response and send it to QFE8. 
904 (not shown): Receive a TRMReserve indication. If it is not possible to meet the requested QoS demands, 

formulate a negative TRMReserve response and send it to QFE8. 
905: When the Reservation Hold Timer expires, release the reserved resources and set an indication that 

they are no longer available. 

5.4 QoS Functional entity behaviour 

The behaviour specified in this clause is intended to illustrate typical QFE behaviour in terms of information flows sent 
and received. 

The behaviour of each QFE is shown using the Specification and Description Language (SDL) defined in 
ITU-T Recommendation Z.100 [6]. 

NOTE: The complete SDL model which was used for validation purposes (and from which the following process 
diagrams were extracted) is available separately in electronic form. 

5.4.1 Information flows specified as ASN.1 operations 

For the purposes of modelling end-to-end QOS signalling in SDL, the information flows defined in subclause 5.2 have 
been specified using the Abstract Syntax Notation 1 (ASN.l) defined in ITU-T Recommendation X.680 [7]. The ASN.l 
is shown in table 10. 

Table 10: End-to-end QoS information flows specified as ASN.1 

TIPHON-QoS-Types DEFINITIONS ::= 

BEGIN 

— Data structures for the OrigQoSEstab signals — 

CallReqType ::= SEQUENCE 
{ qoSServiceClass QoSClass, 
calledUserlD TiphonUserName, 
codec CodecList } 

CallRespType ::= SEQUENCE 
{ codec CodecList OPTIONAL, 
result OrigResult } 

origResultOnly CallRespType ::= { result qoSNotAvailable } 

QoSClass ::= INTEGER (0 . .maxQoSClass) 

maxQoSClass INTEGER ::= 255 

predef inedQoS QoSClass ::= 

1 



tiphonQoSClass-1 QoSClass : 
tiphonQoSClass-2A QoSClass 
tiphonQoSClass-2M QoSClass 
tiphonQoSClass-2H QoSClass 
tiphonQoSClass-3 QoSClass : 



= 2 
= 3 

= 4 
5 



NonStandardQoSClass ::= QoSClass (16 . .maxQoSClass) 
TiphonUserName ::= E164Number 
E164Number ::= NumericString (SIZE (1..15)) 
CodecList ::= SEQUENCE (SIZE (1..8)) OF CodecType 
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CodecType ::= SEQUENCE 

{ codecID CodecID, 

f ramesperPacket FrameCount } 

CodecID ::= VisibleString (SIZE (1..15)) 

FrameCount ::= INTEGER ( 1 . .maxFrameCount ) 

maxFrameCount INTEGER ::= 256 

OrigResult ::= ENUMERATED 
{ requestedQoSEstablished, 
qoSNotAvailable, 
unknownUser, 
noCompatibleCodec, 
policyRe jection } 

— Data structures for the QoSEstab Signals — 

QoSReqType ::= SEQUENCE 

{ callingUserlD TiphonUserName, 

calledUserlD TiphonUserName, 

transportQoSParams TransportParams, 

paramQualif ier ParamQualif ier, 

codec CodecList, 

destServiceDomain NWspecif icAddr OPTIONAL } 

QoSRespType ::= SEQUENCE 
{ codec CodecList OPTIONAL, 
result QoSEstabResult } 

qosResultOnly QoSRespType ::= { result qoSNotAvailable } 

TransportParams ::= SEQUENCE 
{ maximumDelay Microseconds, 
maxDelayVariation Microseconds, 
maxMeanPacketLoss PercentXIOOO 

— Packet loss is specified as % x 1000 to avoid — 

— the need for REAL numbers when loss is less — 

— than one percent — } 

Microseconds ::= INTEGER (0 .. 10000000) — Allows up to 10s to be expressed in micro-sec 

PercentXIOOO ::= INTEGER (0 .. 100000 ) — Allows up to 100% to be expressed in — 

— increments of 0.001% — 

ParamQualif ier ::= ENUMERATED 
{ totalRemainingBudget , 
budgetAvailableForDomain } 

NWspecif icAddr ::= CHOICE 
{ el64Number [0] E164Number, 
e212Number [1] E212Number, 
ipAddress [2] IPAddress } 

E212Number ::= NumericString (SIZE (15)) 

IPAddress ::= CHOICE 

{ ipv4Address [0] IPv4Address, 

ipv6Address [1] IPv6Address } 

IPv4Address ::= SEQUENCE 
{ addr FourOctets, 
port OneOctet } 

IPv6Address ::= SEQUENCE 
{ addr SixteenOctets, 
port SixteenOctets } 

OneOctet ::= OCTET STRING (SIZE (1)) 
FourOctets ::= OCTET STRING (SIZE (4)) 
SixteenOctets ::= OCTET STRING (SIZE (16)) 

QoSEstabResult ::= ENUMERATED 
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{ qoSAvailable, 
qoSNotAvailable, 
unknownUser, 
noCompatibleCodec } 



— Data structures for the DestQoSEstab signals — 

CalledReqType ::= SEQUENCE 
{ callingUserlD TiphonUserName, 
transportQoSParams TransportParams, 
codec CodecList } 

CalledRespType ::= SEQUENCE 
{ codec CodecList OPTIONAL, 
result DestResult } 

DestResult ::= ENUMERATED 
{ indicatedCodecSelected, 
codecsNotSupported } 



— Data structures for the QoSPolicyReq signals 

PolicyReqType ::= SEQUENCE 
{ callingUserlD TiphonUserName, 
calledUserlD TiphonUserName, 
requestedQoS RequestedQoS } 



PolicyRespType 



PolicyResult 



RequestedQoS ::= CHOICE 

{ transportQoSParams TransportParams, 

qoSServiceClass QoSClass } 

PolicyResult ::= ENUMERATED 
{ callAllowed, 
serviceNotSubscribedTo, 
serviceCurrentlyNotAvailable } 



— Data structures for the TRMReserve signals — 

TRMResType ::= SEQUENCE 
{ requestHandle Handle, 
transportQoSParams TransportParams, 
paramQualif ier ParamQualif ier, 
traf f icDescriptor TrafficDesc, 
ingressAddress NWspecif icAddr, 
destTranspDomain NWspecif icAddr } 

TRMRespType ::= SEQUENCE 

{ transportQoSParams TransportParams OPTIONAL, 

trmResResult TRMResResult } 

resultOnly TRMRespType ::= { trmResResult bandwidthReserved 

Handle ::= VisibleString (SIZE (0..16)) 

TrafficDesc ::= SEQUENCE 
{ peakFrameRate FrameRate, 
maxFrameLength FrameLength } 

FrameRate ::= INTEGER (1..255) 

FrameLength ::= INTEGER (1.. 65535) 

TRMResResult ::= ENUMERATED 
{ bandwidthReserved, 
bandwidthUnavailable, 
destinationUnknown } 



-- Data structures for TRMConnect signals -- 
TRMConnectType ::= Handle 
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TRMConnRespType : 


= TRMConnResult 






TRMConnResult ::= 


ENUMERATED 






{ connectionMade, 








unableToConnect } 








— Data structures 


for TRMRelease 


si 


gnal — 


TRMReleaseType : : 


= Handle 






END 









5.4.2 Behaviour of QFE1 

The behaviour of QFE1 is shown in the SDL process diagram in figures 10 to 13. 
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Figure 10: SDL process diagram for functional entity QFE1 (1 of 4) 
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Figure 11 : SDL process diagram for functional entity QFE1 (2 of 4) 
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Figure 12: SDL process diagram for functional entity QFE1 (3 of 4) 
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Figure 13: SDL process diagram for functional entity QFE1 (4 of 4) 
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5.4.3 Behaviour of QFE2, QFE3 and QFE8 

The behaviour specifications of functional entities QFE2, QFE3 and QFE8 are, for the purposes of the present 
document, identical. This behaviour is shown in the SDL process type diagram in figures 14 to 20. 
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Figure 14: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (1 of 7) 
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Figure 15: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (2 of 7) 
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Figure 16: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (3 of 7) 



ETSI 



39 



ETSI TS 102 024-3 V4.1.1 (2003-01) 



PROCESS TYPE Service FE 



Normal 
Behaviour 

7 



budget_ 
Available_ 
For_ 
Domain 



bandwidth_ 
Reserved 





^ Qua 


tier ^> 

total_ 

Remair 
Budget 


ing_ 






Remaining 
QoSParam s := 




QoSParamsFrom 

(Reservation_ 

Response) 
















Request := 




Add_QoSParams_From 
(RemainingQoSParams, 
Request) 






\ 










? 




QoSEstab_ri \ 
(Request) / 




VIA Service_U 




N 


' 







WaitFor_ 
Establishement_ 
nse 



4(7) 



(WaitFor_ 
TRM_Response 



TRMReserve_rc, 
(Reservation 
Response) 



FROM Transport 




ResultFrom 

(Reservation_ 

Response) 



bandwidth_ 
Unavailable 



destination_ 
Unknown 



EstabResult := 
qosNotAvailable 



/* 

Exceptional 

Behaviour 

V 



EstabResult := 
unknownUser 



TRMRelease_ri 
(CallHandle; 




VIA Transport 



Request_ 
Response : 



AddResultFrom 

(EstabResult, 

RequestResponse) 



QoSEstab_rc 

(Request_ 

Response) 




VIA Service D 



Figure 17: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (4 of 7) 
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Figure 18: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (5 of 7) 
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Figure 19: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (6 of 7) 
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Figure 20: SDL process type diagram for functional entities QFE2, QFE3 and QFE8 (7 of 7) 
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5.4.4 Behaviour of QFE6, QFE7 and QFE9 

The behaviour specifications of functional entities QFE6, QFE7 and QFE9 are, for the purposes of the present 
document, identical. This behaviour is shown in the SDL process type diagram in figures 20 to 24. 
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Figure 21 : SDL process type diagram for functional entities QFE6, QFE7 and QFE9 (1 of 5) 
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Figure 22: SDL process type diagram for functional entities QFE6, QFE7 and QFE9 (2 of 5) 
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Figure 23: SDL process type diagram for functional entities QFE6, QFE7 and QFE9 (3 of 5) 
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Figure 24: SDL process type diagram for functional entities QFE6, QFE7 and QFE9 (4 of 5) 
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Figure 25: SDL process type diagram for functional entities QFE6, QFE7 and QFE9 (5 of 5) 

5.4.5 Behaviour of QFE4 

The behaviour of QFE4 is shown in the SDL process diagram in figures 26 to 29. 
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Figure 26: SDL process diagram for functional entity QFE4 (1 of 4) 
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Figure 27: SDL process diagram for functional entity QFE4 (2 of 4) 
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Figure 28: SDL process diagram for functional entity QFE4 (3 of 4) 
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Figure 29: SDL process diagram for functional entity QFE4 (4 of 4) 

5.4.6 Behaviour of QFE5 

The behaviour of QFE5 is shown in the SDL process diagram in figure 30. 
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Figure 30: SDL process diagram for functional entity QFE5 
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5.5 Allocation of functional entities to domains 



The possible allocation of QFEs to TIPHON domains is shown in table 1 1 where: 



TE 

OSD 

OTD 

DSD 

DTD 

IVSD 

IVTD 



indicates Terminal Equipment; 

indicates the Originating user's Service Domain; 

indicates the Transport Domain associated with the Originating user; 

indicates the Destination user's Service Domain; 

indicates the Transport Domain associated with the Destination user; 

indicates an Intervening Service Domain; and 

indicates an Intervening Transport Domain. 



Table 1 1 : Allocation of QFEs to TIPHON domains 



Scenario 


QFE1 


QFE2 


QFE3 


QFE4 


QFE5 


QFE6 


QFE7 


QFE8 


QFE9 


a 


TE 


OSD 


DSD 


TE 


OSD 


OTD 


DTD 


IVSD 


IVTD 


b 


OSD 


OSD 


DSD 


DSD 


OSD 


OTD 


DTD 


IVSD 


IVTD 


c 


OSD 


OSD 


DSD 


DSD 


OSD 


OTD 


DTD 


IVSD 


IVTD 


d 


TE 


OSD 


DSD 


DSD 


OSD 


OTD 


DTD 


IVSD 


IVTD 


e 


OSD 


OSD 


DSD 


DSD 


OSD 


OTD 


DTD 


OSD 


IVTD 


f 


OSD 


OSD 


DSD 


DSD 


OSD 


OTD 


DTD 


OSD 


OTD 


g 


OSD 


OSD 


DSD 


DSD 


OSD 


OTD 


OTD 


OSD 


OTD 



This table is not exclusive and other allocation scenarios may also legitimately exist. However, the following limitations 
shall apply: 



QFE1 
QFE2 
QFE3 
QFE4 
QFE5 
QFE6 
QFE7 
QFE8 
QFE9 



shall only be allocated to either TE or OSD; 

shall only be allocated to OSD; 

shall only be allocated to DSD; 

shall only be allocated to either TE or DSD; 

shall always be allocated to OSD; 

shall always be allocated to OTD; 

shall only be allocated to either DTD or OTD; 

shall be allocated to either IVSD or OSD; and 

shall only be allocated to either IVTD or OTD. 



The allocations specified in table 1 1 are shown graphically in annex A. 
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Annex A (informative): 

Graphical representation of QFE allocation scenarios 

The diagrams shown in figures A. 1 to A.7 illustrate graphically the legitimate allocation of QFEs to TIPHON domains 
as specified in table 1 1 . 
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Figure A.1 : QFE Allocation Scenario a 
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Figure A.2: QFE Allocation Scenario b 
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Figure A.3: QFE Allocation Scenario c 
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Figure A.5: QFE Allocation Scenario e 
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Figure A.6: QFE Allocation Scenario f 
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Annex B (informative): 

Mappings of QoS meta-protocol to H.323 series protocols 



B.1 Introduction 



For each element in each of the QoS Signalling information flows, the tables in this annex identify where and how the 
information can be obtained or sent in the H.323 [8] series of protocols (H.225.0 [9] and H.245 [10]). The underlying 
architectural model of H.323 is simpler than the TIPHON model as there is no provision for guaranteed QoS in H.323. 
This means that some of the mappings in this annex are tentative, speculative or non-existent. In each case, notes in the 
tables identify the status of the mappings. 



B.2 OrigQoSEstab 



Table B.1 : Mapping of OrigQoSEstab request 



OrigQoSEstab request 


H.225 


Information element 


Value 


Mapping 


Notes 


QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


No equivalent 


Can be implied from the bearer 
capability IE in the Q.931 Setup 
message, particularly for 
voice-only calls. A Bearer 
capability of "speech" or 
"3,1 kHz audio" maps to a QoS 
Service Class of "TIPHON 2H". 


Called user ID 


TIPHON user name 


ARQ destinationlnfo 

a single entry as an E.1 64 
number 


TS 1 02 024-3 specifies an 
E. 1 64 number as a 1 to 1 5 digit 
numeric string. H225.0 specifies 
it as a 1 to 128 character IA5 
string 


Codec 


- List of possible codecs 
Codec type 
Frames per packet 


No equivalent 
(H.245 uses its 
TerminalCapabilitySet 
message to communicate 
codec information. As this is 
an end-to-end signal, it does 
not provide a valid mapping 
with OrigQoSEstab) 


Can be implied to some extent 
from the bearer capability IE in 
the Q.931 Setup message, 
particularly for voice-only calls. 
A bearer capability of "speech" 
or "3,1 kHz audio" maps to a 
Codec type of " G.71 1 ". As a 
default, the Frames per packet 
should be set to the value 20 in 
this case (see note). 


NOTE: The value of 20 G.71 1 samples per packet is not entirely arbitrary but is based on the common use of 20 or 30 
in existing devices which packetize G.71 1 sample streams. However, there appears to be no published 
research on determining the optimum value. 
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Table B.2: Mapping of OrigQoSEstab response 



OrigQoSEstab response 


H.225 


Information element 


Value 


Mapping 


Notes 


Codec 


- List of possible codecs 

- Codec type 
Frames per packet 


No equivalent 


This information could be 
carried in the ACF genericData 
IE. The codec type can use the 
type "text" and the frames per 
packet can use the type 
"number8" 


Result 


- End-to-end QoS 
Established 

- with requested QoS 
Rejection cause 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 

- Policy Rejection 


ACF 

ARJ rejectReason 

- resourceUnavailable 

- calledPartyNotRegistered 

- no direct mapping 

- invalidPermission 





B.2.1 Additional H.225. ARQ settings for OrigQoSEstab 

The transportQOS information element in the H. 225.0 ARQ message should be set to the value gatekeeperControlled. 
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B.3 QoSEstab 



Table B.3: Mapping of QoSEstab request 



QoSEstab request 


H.225 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


ARQ srclnfo 

a single entry as an 
E.164 number 


The present document specifies 
an E.164 number as a 1 to 15 
digit numeric string. H225.0 
specifies it as a 1 to 128 
character IA5 string 


Called user ID 


TIPHON user name 


ARQ destinationlnfo 
a single entry as an 
E.164 number 


The present document specifies 
an E.164 number as a 1 to 15 
digit numeric string. H225.0 
specifies it as a 1 to 128 
character IA5 string 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE. Delay and delay variation 
can use the type "number16" 
and packet loss can use the 
type "number32" 


Transport parameters 
qualifier 


- Transport QoS parameters 
indicate total remaining budget 

- Transport QoS parameters 
indicate budget available per 
domain 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE using the type "number8" 


Traffic descriptor 


Media peak rate, 
Maximum media frame size, 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE. The peak rate can use the 
type "number8" and the 
maximum frame size can use 
the type "number16" 


Codec 


List of possible codecs 
- Codec type 

Frames per packet 


No equivalent 
(H.245 uses its 
TerminalCapabilitySet 
message to communicate 
codec information. As this 
is an end-to-end signal, it 
does not provide a valid 
mapping with QoSEstab) 


This information could be 
carried in the ARQ genericData 
IE. The codec type can use the 
type "text" and the frames per 
packet can use the type 
"number8" 


Destination service 
domain 


Network specific address 


ARQ 
destCallSignalAddress 


For both IPv4 and IPv6 
addresses, there is an exact 
mapping of the address portion 
itself. However, the present 
document specifies the port as 
a 16 octet string while H. 225.0 
specifies it as a 16-bit integer 
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Table B.4: Mapping of QoSEstab response 



QoSEstab response 


H.225 


Information element 


Value 


Mapping 


Notes 


Codec 


List of possible codecs 
- Codec type 

Frames per packet 


No equivalent 


This information could be 
carried in the ACF genericData 
IE. The codec type can use the 
type "text" and the frames per 
packet can use the type 
"number8" 


Result 


Requested QoS available 
Rejection cause 
Requested QoS not 
available 

Called user unknown 
- No compatible codec 
available 


ACF 

ARJ rejectReason 

resourceUnavailable 

calledPartyNotRegistered 

no direct mapping 





B.3.1 Additional H.225. ARQ settings 

transportQOS should be set to gatekeeperControlled. 



B.4 DestQoSEstab 



Table B.5: Mapping of DestQoSEstab request 



DestQoSEstab request 


H.225 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


ARQ srclnfo 

a single entry as an E.1 64 
number 


The present document specifies 
an E.1 64 number as a 1 to 15 
digit numeric string. H225.0 
specifies it as a 1 to 128 
character IA5 string 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay 

variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE. Delay and delay variation 
can use the type "number16" 
and packet loss can use the 
type "number32" 


Codec 


List of possible codecs 
- Codec type 

Frames per packet 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE. The codec type can use the 
type "text" and the frames per 
packet can use the type 
"number8" 



Table B.6: Mapping of DestQoSEstab response 



DestQoSEstab response 


H.225 


Information element 


Value 


Mapping 


Notes 


Codec 


List of possible codecs 
- Codec type 

Frames per packet 


No equivalent 


This information could be 
carried in the ACF genericData 
IE. The codec type can use the 
type "text" and the frames per 
packet can use the type 
"number8" 


Result 


Indicated codec selected 
Rejection cause: 
- Codecs not supported 


ACF 

ARJ rejectReason 
no direct mapping 
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B.5 QoSPolicy 



The H.323 model does not include a policy entity and so there is no equivalent to the QoSPolicy protocol messages. 
Consequently, it is not possible to make any definite mapping between the TIPHON meta-protocol and H.323 in this 
area. However, it may be useful to consider the Clearing House Border Element (BE C h) described in annex G of 
ITU-T Recommendation H. 225.0 [9] as performing this function. 

Table B.7: Mapping of QoSPolicy request 



QoSPolicy request 


H.225 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


ARQ srclnfo 

a single entry as an E.1 64 
number 


The present document specifies 
an E.1 64 number as a 1 to 15 
digit numeric string. H225.0 
specifies it as a 1 to 128 
character IA5 string 


Called user ID 


TIPHON user name 


ARQ destinationlnfo 

a single entry as an E.1 64 
number 


The present document specifies 
an E.1 64 number as a 1 to 15 
digit numeric string. H225.0 
specifies it as a 1 to 128 
character IA5 string 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay 

variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE. Delay and delay variation 
can use the type "number16" 
and packet loss can use the 
type "number32" 


QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


No equivalent 


This information could be 
carried in the ARQ genericData 
IE using the type "number8" 



Table B.8: Mapping of QoSPolicy response 



QoSPolicy response 


H.225 


Information element 


Value 


Mapping 


Notes 


Result 


- Call permitted 


ACF 






- Rejection cause 


ARJ rejectReason 






Service not 


invalidPermission 






subscribed to 








Service currently 


neededFeatureNotSupported 






not available 







B.6 TRMReserve, TRMConnect, TRMRelease 

The H.323 series of standards are explicitly intended for providing communications without a guarantee of QoS. As a 
consequence, the underlying model is different from the TIPHON model. H.323 assumes a direct, but uncontrolled 
media path to the destination whereas TIPHON assumes linked transport domains carefully controlled by service 
domains to ensure that sufficient resources are available that the desired QoS can be achieved. There is, therefore, no 
functional equivalence in H.323 to the messages that pass between a TIPHON service domain and the corresponding 
transport domain (TRMReserve, TRMConnect and TRMRelease) and, thus, no mapping of meta-protocol information 
elements to H.323 signals is possible. 
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B.7 Summary of mapping QoS meta-protocol to H.323 
series 

Although, with some assumptions, it is possible to show how H. 225.0 can be mapped to the TIPHON QoS 
meta-protocol between users and service domains and between service domains and service domains, there is no 
provision in the current version of the H.323 series of standards for any signalling between service domains and 
transport domains. Since this signalling is fundamental to the provision of guaranteed QoS in the TIPHON model, there 
is a significant gap in the mappings. To achieve full mapping, there needs to be a revision of the H.323 architecture as 
well as considerable modifications to the protocols themselves. This should include: 

1 ) the clear recognition that there are entities which can at least act as service domains between the calling user 
and the called user; 

2) the modification of H. 225.0 to provide communication between user and service domain as well as between 
service domain and service domain; 

3) the addition within the H.323 architecture of transport domains distinct from the current administrative 
domains and a specific Policy Entity; 

4) the addition of specific protocol within H. 225.0 for making enquiries to the Policy Entity (possibly based on 
TIPHON OSP[l]); 

5) the addition of a completely new protocol recommendation for signalling between service domains and 
transport domains; 

6) the addition within the H. 225.0 ARQ message of information elements to carry QoS class, Transport QoS 
Parameters, the Transport Parameters Qualifier, the Traffic descriptor and Codec lists; 

7) the addition within the H. 225.0 ACF message of an information element to carry a Codec descriptor. 
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Annex C (informative): 

Mappings of QoS meta-protocol to SIP and associated 

protocols 



C.1 Introduction 



For each element in each of the QoS Signalling information flows, the tables in this annex identify where and how the 
information can be obtained or sent in the Session Initiation Protocol (SIP) [15] and its associated protocols, the Session 
Description Protocol (SDP) [12], and the Real-Time Protocol Audio-Video Profile (RTP/AVP) [11]. As with H.323, the 
underlying architectural model of SIP is simpler than the TIPHON model as there is no provision for guaranteed QoS. 
This, again, means that some of the mappings in this annex are tentative, speculative or non-existent. In each case, notes 
in the tables identify the status of the mappings. 



C.2 OrigQoSEstab 



Table C.1 : Mapping of OrigQoSEstab request 



OrigQoSEstab request 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


The suggested attribute for 
quality (a=quality:<quality>) in 
SDP offers an integer range of 

to 10. These can be mapped 
thus: 

OTIPHON Class 1 

1 TIPHON Class 2A 

2 TIPHON Class 2M 

3 TIPHON Class 2H 

4 TIPHON Class 3 

5 Predefined 

6-10 Non-standardized 
QoS classes 


The "quality" attribute is 
intended primarily for video 
media streams but there is 
nothing in RFC2327 [12] which 
would prevent it being used for 
voice QoS 

Although the range suggested 
for the SDP quality attribute is 
to 10, there is no reason why 
this could not be extended to 
the TIPHON range of to 255 


Called user ID 


TIPHON user name 


SIP INVITE "To" header field 
using the tel URL format 


For simple mapping to TIPHON 
user name, the To field should 
be formulated as a telephone- 
url as specified in 
RFC 2806 [14] 


Codec 


- List of possible codecs 

- Codec type 

- Frames per packet 


SDP media announcements 
(m) sub-field, media formats. 
This can carry a list of 
RTP/AVP codes for available 
codec types. For example, to 
use G.71 1 , it is necessary to 
select the u-Law PCM code 
"0", as follows: 
m=audio 49232 RTP/A VP 

No equivalent to Frames per 
packet 


As a default, the Frames per 
packet should be set to the 
value 20 in this case (see note) 


NOTE: The value of 20 G.71 1 samples per packet is not entirely arbitrary but is based on the common use of 20 or 30 
in existing devices which packetize G.71 1 sample streams. However, there appears to be no published 
research on determining the optimum value. 
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Table C.2: Mapping of OrigQoSEstab response 



OrigQoSEstab response 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


Codec 


- List of possible codecs 

- Codec type 

- Frames per packet 


No equivalent response 


Both the codec type an the 
Frames per packet information 
could be carried as a 
TIPHON-defined attribute (a) 
sub-fields in SDP 


Result 


- End-to-end QoS 
Established 

- with requested QoS 
Rejection cause 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 

- Policy Rejection 


SIP INVITE response 200 
SIP INVITE request failure 

- 415: 

Unsupported media type 

- 404: Not found 

- no direct mapping 

- 406: Not acceptable 
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C.2 QoSEstab 



Table C.3: Mapping of QoSEstab request 



QoSEstab request 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


SIP INVITE "From" header 
field using the tel URL format 


For simple mapping to TIPHON 
user name, the To field should 
be formulated as a 
telephone-url as specified in 
RFC 2806 [14] 


Called user ID 


TIPHON user name 


SIP INVITE "To" header field 
using the tel URL format 


For simple mapping to TIPHON 
user name, the To field should 
be formulated as a 
telephone-url as specified in 
RFC 2806 [14] 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay 

variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in a TIPHON-defined 
attribute (a) sub-field in SDP 


Transport parameters 
qualifier 


- Transport QoS parameters 

indicate total 
remaining budget 

- Transport QoS parameters 

indicate budget 
available per 
domain 


No equivalent 


This information could be 
carried in a TIPHON-defined 
attribute (a) sub-field in SDP 


Traffic descriptor 


Media peak rate, 
Maximum media frame size, 


No equivalent 


This information could be 
carried in a TIPHON-defined 
attribute (a) sub-field in SDP 


Codec 


List of possible codecs 

- Codec type 

- Frames per packet 


SDP media announcements 
(m) sub-field, media formats. 
This can carry a list of 
RTP/AVP codes for available 
codec types. For example, to 
use G.71 1 , it is necessary to 
select the u-Law PCM code 
"0", as follows: 
m=audio 49232 RTP/A VP 

No equivalent to Frames per 
packet 


The Frames per packet 
information could be carried as 
a TIPHON-defined attribute (a) 
sub-field in SDP 


Destination service 
domain 


Network specific address 


Connection address sub-field 
in the SDP connection data (c) 
field 


Current edition of SDP supports 
only IPV4 addresses 



Table C.4: Mapping of QoSEstab response 



QoSEstab response 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


Codec 


List of possible codecs 

- Codec type 

- Frames per packet 


No equivalent response 


Both the codec type an the 
Frames per packet information 
could be carried as a 
TIPHON-defined attribute (a) 
sub-fields in SDP 


Result 


- Requested QoS available 

- Rejection cause 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 


SIP INVITE response 200 
SIP INVITE request failure 

- 415: 

Unsupported media type 

- 404: Not found 

- 406: Not acceptable 
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C.3 DestQoSEstab 



Table C.5: Mapping of DestQoSEstab request 



DestQoSEstab request 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


SIP INVITE "From" header 
field using the tel URL format 


For simple mapping to TIPHON 
user name, the To field should 
be formulated as a 
telephone-url as specified in 
RFC 2806 [14]. 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay 

variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in a TIPHON-defined 
attribute (a) sub-field in SDP 


Codec 


List of possible codecs 

- Codec type 

- Frames per packet 


SDP media announcements 
(m) sub-field, media formats. 
This can carry a list of 
RTP/AVP codes for available 
codec types. For example, to 
use G.71 1 , it is necessary to 
select the u-Law PCM code 
"0", as follows: 
m=audio 49232 RTP/A VP 

No equivalent to Frames per 
packet 


The Frames per packet 
information could be carried as 
a TIPHON-defined attribute (a) 
sub-field in SDP 



Table C.6: Mapping of DestQoSEstab response 



DestQoSEstab response 


SIP/SDP/RTP/AVP 


Information element 


Value 


Mapping 


Notes 


Codec 


List of possible codecs 


No equivalent 


Both the codec type an the 




- Codec type 




Frames per packet information 




- Frames per packet 




could be carried as a 
TIPHON-defined attribute (a) 
sub-fields in SDP 


Result 


- Indicated codec selected 


SIP INVITE response 200 






- Rejection cause: 


SIP INVITE request failure 






Codecs not supported 


- 406: Not acceptable 





C.4 QoSPolicy 



The SIP model does not include a policy entity and so there is no equivalent to the QoSPolicy protocol messages. 
Consequently, it is not possible to make any mapping between the TIPHON meta-protocol and SIP in this area. 
However, the Common Open Policy Service (COPS) protocol [13] used by RSVP exists specifically for this purpose. 
Its underlying architectural model is similar to the TIPHON QoS model in that COPS provides communication between 
a network node and a policy entity referred to as the Policy Decision Point (PDP). Tables C.7 and C.8 show how the 
meta-protocol information flow, QoSPolicy, can be mapped to COPS. 
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Table C.7: Mapping of QoSPolicy request 



QoSPolicy request 


COPS 


Information element 


Value 


Mapping 


Notes 


Calling user ID 


TIPHON user name 


COPS REQ 

C-num = 3 In Interface 

C-type =1 (IPv4) or 2 (IPv6) 


COPS permits only an IPv4 or 
IPv6 address. The TIPHON 
user name would need to be 
converted from an E.164 
number before use 


Called user ID 


TIPHON user name 


COPS REQ 

C-num = 4 Out Interface 

C-type =1 (IPv4) or 2 (IPv6) 


COPS permits only an IPv4 or 
IPv6 address. The TIPHON 
user name would need to be 
converted from an E.164 
number before use 


Transport QoS 
parameters 


Maximum delay, 

Maximum packet delay 

variation, 

Maximum mean packet loss 


No equivalent 


This information could be 
carried in the ClientSI object 
(C-num = 9, C-type = 1) 


QoS Service Class 


- Predefined 
-TIPHON QoS class 

- 3 Best 
-2H High 

- 2M Medium 

- 2A Acceptable 
- 1 Best effort 

- Non-standardized QoS class 


No equivalent 


This information could be 
carried in the ClientSI object 
(C-num = 9, C-type = 2) 



Table C.8: Mapping of QoSPolicy response 



QoSPolicy response 


COPS 


Information element 


Value 


Mapping 


Notes 


Result 


- Call permitted 

- Rejection cause 

Service not 
subscribed to 
Service currently 
not available 


COPS DEC 

C-num = 6, C-type = 1 ; 4 

COPS DRQ 

C-num = 5 

C-type = 1 ; 9 

C-type = 1 ; 7 


C-Type 1 ; 4 = Admit Request 

C-Type 1,9 = Unsupported 
decision 

C-type 1,7 = Insufficient 
resources 



C.5 TRMReserve, TRMConnect, TRMRelease 

SIP and its associated standards are intended for providing communications without a guarantee of QoS. As a 
consequence, the underlying model is different from the TIPHON model. SIP assumes a direct, but uncontrolled media 
path to the destination whereas TIPHON assumes linked transport domains carefully controlled by service domains to 
ensure that sufficient resources are available that the desired QoS can be achieved. There is, therefore, no functional 
equivalence in SIP or SDP to the messages that pass between a TIPHON service domain and the corresponding 
transport domain (TRMReserve, TRMConnect and TRMRelease) and, thus, no mapping of meta-protocol information 
elements to SIP, SDP or RTP/AVP signals is possible. 
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C.6 Summary of mapping of QoS meta-protocol to SIP, 
SDP, RTP/AVP and COPS 

Although, with some assumptions, it is possible to show how SIP and SDP can be mapped to the TIPHON QoS meta- 
protocol between users and service domains and between service domains and service domains, there is no provision in 
the current version of the IETF series of standards for any signalling between service domains and transport domains. 
Since this signalling is fundamental to the provision of guaranteed QoS in the TIPHON model, there is a significant gap 
in the mappings. To achieve full mapping, there needs to be considerable modifications to the SIP -related protocols. 
This should include: 

1 ) the clear recognition that there are entities which can at least act as service domains between the calling user 
and the called user; 

2) the addition within the SIP/SDP architecture of transport domains; 

3) the addition of a new protocol specification for signalling between service domains and transport domains; 

4) the extension of COPS to include fields for carrying QoS Class or Transport QoS Parameters; 

5) the extension of SDP to include fields for carrying QoS class, Transport QoS Parameters, the Transport 
Parameters Qualifier, the Traffic descriptor and Codec lists. 
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